Looks like it's all working fine! 🚀

Yes... took me good while to make it that way :D

Will do some more refactoring before I merge, though.

Refactor done, this is in great shape now. Will merge if all pipelines pass.

@develop7 please have a look at the pipelines in this PR. All the "Text .. (Nix)" pipelines, which should benefit from the prepopulate job, are building the same dependencies again, that the prepopulate job had to build. I think we are missing postgrestPackage as a "tool" in the prepopulate job, because that contains all the haskell dependencies for the dynamic build - which is used in all tests etc.

Edit: At the same time, I think the "CI / Build Linux static (Nix)" job does not need to wait on the prepopulate job. It doesn't benefit from it at all, because it only builds the static parts, which are not cached there anyway.

@wolfgangwalther thanks for both the heads-up and the suggestion as well! I've noticed the unnecessary rebuilds yesterday and were a wee bit stuck fixing them. Trying it now.

@wolfgangwalther didn't help. I've filed nix-community/cache-nix-action#27 and about to revert cache-nix-action back to 4.x. Honestly, I didn't quite expect them to break the cache restore part :)

After merging, the Cachix / Seed Linux job failed. I didn't know it existed and it only runs on main. Should be fixed in 071a3d4.

This MR broke the docker image. The artifact postgrest-docker-x64 is now 380 MB big and includes all kinds of /nix/store paths... will look into that.

Before this change, the static executable was ~5 MB. Now it's ~12 MB - very similar to all the other dynamic builds. The docker image containers 370 MB of dependencies.

This all looks like the build is actually dynamically linked. Yet:

file postgrest
postgrest: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

The file size could be related to this:

https://github.com/nh2/static-haskell-nix/blob/88f1e2d57e3f4cd6d980eb3d8f99d5e60040ad54/survey/default.nix#L11-L17

TODO Find out why pkgsStatic creates ~3x larger binaries.

The big number of dependencies seem to be added, because all the haskell dependencies are now listed in propagatedBuildInputs for the new derivation. This was not the case with static-haskell-nix before.

Perhaps https://github.com/nlewo/nix2container could help? I've heard it's lighter on the nix store. References:

• https://blog.eigenvalue.net/2023-nix2container-everything-once/
• https://lewo.abesis.fr/posts/nix-build-container-image/
• also see https://github.com/pdtpartners/nix-snapshotter

Perhaps https://github.com/nlewo/nix2container could help? I've heard it's lighter on the nix store.

I think that would only change the way the docker image is created - but the problem is the input we are giving to this tool. The input has changed, and this is a problem. The main difference, from what I can tell, is:

• the old way had all the haskell dependencies in buildInputs
• the new way has all the haskell dependencies in propagatedBuildInputs

This both works fine for actually building the static executable - but when using this derivation somewhere else (docker, here) then all the propagated build inputs are carried with it, and that's what lands in the image.

I'm pretty sure that both findings (executable is bigger and closure for docker image is bigger) are directly related:

• The old executable had some hardcoded /nix/store/... paths only for a openssl-etc derivation.
• The new executable has more hardcoded /nix/store/... paths: warp, libkrb5, HTTP, libpq, openssl-etc, postgrest itself

Those hardcoded paths are detected as dependencies by nix, and thus copied into the docker image - including many transitive dependencies, which blows up the image size.

Not sure why those new builds are bigger now and contain so much more stuff. But if we fix that, the docker image will immediately become smaller again, too.

propagatedBuildInputs

This had nothing to do with it.

I found the additional store paths in the static libraries as well. The old libpq.a did not have a reference to /nix/store/.../etc/postgresql - but the new one has it. This means that the whole haskell toolchain might not even be involved in this, since libpq itself does not depend on any of that.